Code pages
When you access ORACLE through the DataServer, the DataServer usually retrieves character data as determined by the code page (character set) that ORACLE is using. The DataServer is linked with the ORACLE Call Interface (OCI) and receives data from the OCI, thus the code page that the OCI uses determines the data’s code page. See the ORACLE documentation for more information.
Figure 2–1 shows a possible configuration of code pages for the DataServer components and processes.
In some configurations, the instance might not be using the same code page as the OCI. In this case, conversion between the two code pages occurs when the ORACLE RDBMS sends character data to the OCI.
For OpenEdge applications accessing the DataServer, the schema image identifies the code page of the character data. You must set the code page in the schema image to match the code page used by the OCI. Although the DataServer is linked to the OCI, it cannot automatically determine which code page it uses.
The code page name that you specify in the schema image must be the name by which OpenEdge recognizes the code page. For example, in this configuration, the OCI uses a code page named PC850. This is the same code page that OpenEdge recognizes as ibm850. You then specify ibm850 as the code page for the schema image. You must also specify a collation table that has been defined for the specified code page in the convmap file.
The default code page setting for the schema image is ISO8859-1. You can specify a different code page for the schema image:
- When you create the DataServer schema image for the ORACLE database.
- At any time. However, because changing the code page does not affect the data already in the database, writing data to your database using a different code page can corrupt your database.
- When you load a new schema image with a specified code page into an existing schema holder. In this case, the newly loaded schema’s code page overrides the schema holder’s original code page.
You cannot use the PROUTIL utility to change the database code page.
If you are using one schema holder to hold the schema images of several databases, you can specify a different code page for each schema image.
Note: Do not load data definition (.df) files that contain character translation tables into the schema holder. Using a translation table that is different from the internal table can corrupt data in a database.
Client code page
The OpenEdge client might be using a different code page than the code page defined for the schema image in the schema holder.
Note: If you are using the OpenEdge DataServer for ORACLE to access double-byte character data, the client code page must match the code page of the schema-holder database. The code page of the schema image must match the code page of the ORACLE database. See the "Configuring an international environment" section for more information.
The Internal Code Page (-cpinternal) startup parameter determines the code page that the OpenEdge client uses when manipulating data in memory. If the client uses the -cpinternal startup parameter, then the DataServer translates between the two code pages. You must verify that the convmap.cp file contains a conversion table for the client and the code page setting in the schema image. For example, you might have set the schema image to code page xxx and the client might use code page zzz. The convmap.cp file must include a table that converts from xxx to zzz and from zzz to xxx. If convmap.cp does not include the appropriate table, OpenEdge allows you to define your own conversion table.
OpenEdge also allows you to define your own collation tables; however, customized collation tables have no effect when you use the DataServer to access ORACLE. The ORACLE collation tables are in effect when you perform comparisons and sorts.
For a complete discussion of how OpenEdge handles code-page issues, see OpenEdge Development: Internationalizing Applications .